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SECTION 1. SCOPE 


1.1 Identification . 
This part of the 
performance, design, 
identified as NICBES 
contract, NAS8~35922, 
Huntsville, Alabama. 


specification establishes the requirements for 
test, and qualification of a computer program 
Nickel Cadmium Battery Expert System. This 
is from Marshall Space Flight Center (MSFC) in 


1.2 Functional Summary . 

The specific spacecraft power system configuration selected was the Hubble 
Space Telescope (HST) Electrical Power System (EPS) Testbed located at 
MSFC. A detailed model description of the energy storage components is 
given in Appendix A. Power for the HST comes from a system of 13 Solar 
Panel Arrays (SPAs) linked to 6 Nickel-Cadmium Batteries (discussed in 
Appendix B) which are connected to 3 Busses. An expert system, NICBES, 
will be developed at Martin Marietta Denver Aerospace (MSFC) to recognize 
a testbed anomaly, identify the malfunctioning component and recommend a 
course of action. Besides fault diagnosis, NICBES will be able to 
evaluate battery status, give advice on battery status and provide 
decision support for the operator. Information for the Nickel-Cadmium 
batteries will be extracted through knowledge engineering utilizing the 
"Nickel Cadmium Battery experts" at MSFC who are involved with the HST EPS 
kTestbed. Additional knowledge sources will be elicited from literature 
Searches and personnel at MMDA who have had experience with the operation 
of these batteries. Extensive telemetry of the testbed operating 
conditions will be relayed from a DEC LSI-11 through a RS232 to an IBM-PC 
AT. A Data-Handler will be implemented on the IBM-PC AT to monitor the 
data flow and to summarize and condense the telemetry in a manner 
determined by the needs of the Expert System. Its output will be data 
files for use by the Expert System whose responsibilities are those listed 
above. Due to the single tasking constraints of the IBM-PC AT, the two 
sections of NICBES will be run independently. NICBES will be installed 
and demonstrated at MSFC upon development completion. Verification will 
be done by Software Quality Assurance at MMOA. 


SECTION 2. APPLICABLE DOCUMENTS 

Statement of Work (SOW) - Contract Number NAS8-36922. 

Modification #4, December 31, 1985. 

SAMSO Exhibit 73-3, Standard Engineering Practices for Computer Software 
Design and Development, October 6, 1973. 


SECTION 3. REQUIREMENTS 

3. 1 COMPUTER PROGRAM DEFINITION . 

This section will describe the functional relationship between NICBES and 
the HST EPS Testbed with which it will be running. 
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3.1.1 SYSTEM CAPACITIES . 

Telemetry from the HST battery testbed is sent from a DEC LSI-11 through 
an RS232 at 9600 baud to an IBM PC-AT every one minute. The Data-Handler 
will read the input data, 370 ASCII numbers, integer or 5 place floating 
point, and perform appropriate processing within the one minute time 
frame. Unless a fault is detected, it will continue this task for 12 

complete orbits, 96 minutes per orbit. List formated data files will be 
prepared for use by the Expert System. The Expert System portion of 

NICBES reads the data files and operates accordingly to give fault 
diagnosis, battery status and advise or decision support. The Expert 
System is an interactive system which runs at the direction of the user 
with no timing constraints except for fault diagnosis which must be given 
within 20 minutes of fault detection. 

3.1.2 INTERFACE REQUIREMENTS . 

NICBES can be considered an add-on to the HST EPS Testbed System. In no 
way will it impact the Testbed operation. NICBES will have two modes of 
operation. The Data-Handler, to be written in MICRO_SOFT C, will be 
responsible for reading, processing and writing summarized data output 
files derived from the HST EPS Testbed telemetry. The Expert System will 
be programmed in PROLOG and will perform the fault diagnosis along with 
the battery status, advice and decision support from information in the 
data files created by the Data-Handler. NICBES is connected to the 
Testbed by a RS232. The Expert System and the Data-Handler work 
independently. Print-outs can be obtained from the STAR-SD-lo Printer 
MSFC has acquired to support the IBM-PC AT. 

3.1.3 INTERFACE BLOCK DIAGRAM . 

The Interface Block Diagram for HST EPS Testbed and NICBES is given in 
Figure 1. 

3. 1.2.2 DETAILED INTERFACE DEFINITION . 

Telemetry is sent from a DEC LSI-11 to an IBM-PC AT where the NICBES 
package resides. Refer to SECTION 3.5.1 for a detailed description of the 
telemetry format as well as the format for the data files created by the 
Data-Handler. An Interrupt Handler will be implemented to receive the 
Incoming telemetry accurately. A computer operator starts and stops the 
Data-Handler after which the Expert System can be enacted. The Expert 
System utilizes the output data files from the Data-Handler for its 
analysis. The Expert System is totally interactive, driven by menus and 
user input. There is also an STAR-SD-15 Printer attached to the IBM-PC AT 
so that the user can get a hardcopy of any Expert System screens. 

3.2 DETAILED FUNCTIONAL REQUIREMENTS . 

The following paragraphs will give the detailed functional requirements 
necessary to develop the computer program NICBES. Since NICBES is 
composed of two main sections, the functional requirements will be given 
first for the Data-Handler and then for the Expert System. 
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NICBES FUNCTIONAL DIA6RAM 
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3.2.1 Function Main « 

Main is the driver for the Data-Handler . It calls routines to 

read data, process data, write data files and exit, 

information as include file names, define statements, global 
matrices and arrays will reside in a single include file. 


initialize, 
All header 
st rue t ur as , 


3 . 2 . 1 . 1 Inputs . 

Once the computer operator has started the Data-Handler and checked to 
make sure telemetry is coming across the RS232, there are no further 
actions or inputs required. 


3.2. 1.2 Processing . 

Main controls the calling sequence of all routines. It does little 
processing besides determining the current phase (charge or discharge) and 
keeping track of the orbits. 


3 . 2 . 1 . 3 Outputs . 

A message will be printed to the screen at the end of each orbit. 
Phase and orbit parameters will be passed to other routines. 
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3.2.2 Function Initialization . 

Initialization sets up the data catching scheme which takes over the IBM 
poling techniques and' replaces it with an interrupt handler which takes 
incoming data and puts it in a buffer for program access. 

3 . 2 . 2 . 1 Inputs . 

There are no inputs. 

3. 2. 2. 2 Processing . 

The communication port is set. The globally defined matrices and arrays 
used for processing are initialized. Telemetry is read until the start of 
an orbit is reached signaling the true start of the Data-Handler . : An 

orbit starts at night minute 1 of the discharge phase and ends after the 
charge phase. } 

3. 2. 2.3 Outputs . 

A message is printed when the orbit start is found. 



3.2.3 Function Read Data . 

Telemetry comes in from the DEC LSI-11 every one minute. Read data 
retrieves the telemetry from the interrupt handler buffer — 370 values, 
preceded by an ’A* to indicate the beginning of the data. 

3 . 2 . 3 . 1 Inputs . 

The interrupt handler buffer is accessed to read the telemetry input. 

3. 2. 3. 2 Processing . 

The telemetry is read character by character from the interrupt handler 

buffer into a interim buffer and then put into a globally defined 

structured array using a ’sscanf' command. Telemetry reading will be 

synchronized with the character ’A’ signalling the start of the data 
stream. Telemetry is read in groups. First the header information as 
date, orbit, phase, etc. Then data for each of the six batteries is 
read. Last is solar panel array (SPA) and bus data. Each line of 
telemetry has an associated value, new line and carriage return. If an 

EOF (end of file) is encountered while reading telemetry error checking 

will be activated. No communication will also alert an error checking 
process. In addition, as telemetry is received, fault checking will be 
done against ranges specified in Section 3.2.9, unless it is decided that 
a fault signal will be sent from the DEC LSI-11. 

3. 2. 3. 3 Outputs . 

Telemetry is stored in a globally defined structured array (containing all 
370 data points) for the next stage of processing. The structured array 
will have two columns, one for the last set of telemetry and one for the 
current set. Error messages for communication problems will be written to 
the screen. 
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3.2.4 Function Process Data . 

Telemetry needs to be summarized and condensed. Process data takes data 
stored in the globally defined structured array, performs mathematical 
operations and keeps the results in globally defined buffers until it is 
time to write them to data files. Some stored values are the result of an 
entire orbit’s data while other values are derived and written to output 
files every minute. 

3 . 2 . 4 . 1 Inputs . 

Telemetry which has been stored in the globally defined structured array 
will serve as input. 

3. 2.4. 2 Processing . 

Telemetry is processed by keeping running sums, maximums, minimums and 
averages. There are three cases for processing: End of Charge (EOC), 

End of Discharge (EOD) and Every Minute. The processed data will be 
written to files at the appropriate times. Information needed includes 
EOD battery voltage, high battery voltage during charge, recharge ratio, 
EOD cell voltages, cell voltages at high point during charge, average 
battery temperatures, time on trickle charge, current during 

reconditioning, cell pressure at one-minute intervals during last charge, 
cell voltages, AHI and AHO, current from each of the SPAs and the three 
busses, and orbit number. For most of these parameters, values will be 
kept for the last 12 orbits, based upon an ’’expert’s opinion" that enough 
data could be collected for confident decision making. Following is a 
synopsis of what processing needs to be done for each data file. 


Fault file - Contains a fault flag = 1 if there was a fault 

= 0 if no fault was detected. 

Current file 1 - Contains the current orbit number and 

a reconditioning flag for each battery 
= 1 for reconditioning 
= 0 no reconditioning. 

Current file 2 - Contains Phase (charge or discharge) 

Day_min 

Current from 13 SPAs (Solar Panel Array) 

Voltage from 3 Busses 

Average Temperature per Battery (6) 

Current file 3 - Contains Battery Cell Voltages (23 per battery) 
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Each of the following Data files has 6 rows of data, one for each 
In many of the Data files there are 12 columns, one for each orb 
are listed in chronological order. 

Data file 1 (6x12) - File contains battery voltage taken at EOD 
for last 12 orbits. 

Data file 2 (6x12) - File contains the battery voltage at high 
for the last 12 orbits. There are 23 cells per battery. (Note 1) 


battery . 
it. They 

per orbit 

in-charge 


Data file 3 (6x12) - File contains the recharge ratio = AHO/AHI per orbit 
for 12 orbits. (Note 2) 


Data file 4 (6x36) - File contains cell voltages at EOD, with the high 
value, low value and average of all values, in this order per orbit for 
the last 12 orbits. So a row contains 12 high values, 12 low values and 
then 12 average values. 


Data file 5 (6x36) - File contains cell voltages at high-charge; high, low 
and average of all values, in this order, per orbit for last 12 orbits. 
Each row contains 12 high values, 12 low values and the 12 average values. 
(Note 1) 


Data file 6 (6x23) - File contains 23 cell voltages at EOD for each 
battery, from the latest orbit. 

Data file 7 (6x23) - File contains 23 cell voltages at high-charge for the 
latest orbit. 

Data file 8 (6x48) - File contains the average of the six temperature 
sensors (degrees C) per battery, at two minute intervals 
( Imin , 3min , . . . 95min) over the latest orbit. 

Data file 9 (6x12) - File contains the average battery temperatures per 
orbit for the last 12 orbits. This is the average of the temperature 
averages in Data file 8. 


Data 

then 

orbit 


file 10 (6x46) - File contains the 23 cell pressures 
the 23 cell pressures taken at EOD for each battery 


taken at EOC and 
in the last full 


Data file 11 (6X12) - 

battery per orbit for the 


File contains the time on 
last 12 orbits. (Note 3) 


trickle charge for 


each 
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Data file 12 (6x49) - File contains battery current during reconditioning, 
at 2-minute intervals, for last reconditioning of each battery. It is 
recorded every 2 minutes, only when battery reconditioning flag is 1 and 
only for one orbit. Column 1 contains the' orbit number for which 
reconditioning is occurring. The file contains zeroes until a battery is 
reconditioned. 


Data file 13 - File contains AHO summed over discharge phase per orbit for 
last 12 orbits. (Note 2) 


Note 1 — look for highest voltage of any of the 23 cells in a battery. 
Compare incoming values to it, keeping the highest, until phase changes to 
0. This is used in Data files 2, 5 and 7. 

Note 2 — recharge ratio is AHO/AHI. Keep running sum of AHO when phase is 
0, and running sum of AHI when phase is 1, using battery current. Figure 
recharge ratio at EOC (phase goes to 0). Used in Data files 3 and 13. 

Note 3 — during charge phase, when battery current drops to a low value, 
start counting trickle charge time. Keep incrementing this count each 
minute, until phase goes to 0. 

Note 4 — An orbit starts with discharge phase (0), night minute = 1. 
Charge phase (1) follows, counted by day minutes. There are 96 minutes in 
one orbit. BOC means End of Charge and EOO means End of Discharge. 

3 . 2 . 4 . 3 Outputs . 

Output will be stored in the form of globally defined matrices and arrays 
to keep track of the required processed data. Most of these buffers 
record data over a period of twelve orbits. For the more orbits a 
recycling process is required, i.e., the first column is dropped, the 
others are moved to the left one column and the latest orbital data values 
are put in the 12th column. In this manner only the latest 12 orbits are 
kept . 
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3.2.5 Function Write Files . 

Processed data is written to files, some every one 
at EOC and EOD per orbit. The processed data has 
globally defined matrices and arrays. There are 
which are written to at designated times. 


or two minutes, others 
been stored in various 
seventeen output files 


3 . 2 . 5 . 1 Inputs . 

Summarized and condensed data stored in matrices and arrays will serve as 
input . 


3. 2. 5. 2 Processing . 

The processed data buffers will be written to Data files and Current 
files in list format. The Fault file will be written initially with 
fault flag = 0. It will be changed only when a fault is detected. Th 
Data files will contain a main list composed of 6 sublists, one for eac 
battery. These sublists contain the required values followed by commas 

and enclosed in brackets. An identifier is placed at the beginning of 
each file consisting of the name of the file and an associated number. 

For example, Data file 1: 


show( 1, [[al,bl,cl,dl,el,fl,gl,hl,il,jl,kl,ll] , 


[ a2 , b2 , c2 , d2 , e2 , f2 , g2 ] , 

[a3, ], 

[ a4 ] , 

Ca5 3, 

[a6, ] ] ) . 



In this example there are 12 columns, one per orbit. Orbital data is 
listed in chronological order. 


An example of a Current file is given below: 

cur f ( 2 , [ Phase , Day_min , [ SPA currents ],[ Bus voltages ],[ Battery Temps]];. 


3. 2. 5. 3 Outputs . 

The following output files are 
At EOC: 

Data file 2 
Data file 3 
Data file 5 
Data file 7 
Data file 8 
Data file 9 
Data file 11 
Data file 12 
Every Minute: 

Current file 1 
Current file 2 
Current file 3 


written 

At EOC: 


Data 

file 

1 

Data 

file 

4 

Data 

file 

6 

Data 

file 

10 

Data 

file 

13 


When a fault is detected: 
Fault file 
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3.2.6 Function Finish . 

Finish will serve as the exiting module for the Data-Handler . 


3.2.6. 1 Inputs . 

When the Data-Handler has completed its function, the operator inputs a 
’■'C’ to halt processing. Exiting can also occur after read errors which 
the Data-Handler deems very serious or when a fault is detected.. 


3. 2. 6. 2 Processing . 

There is no processing done in Finish except to call functions to write 
final data files. 

3 . 2 . 6 . 3 Outputs . 

A message will be printed to the screen saying that the Data-Handler is 
exiting. 



3.2.7 Function Interupt Handler . 

The Interupt Handler will take over control of the standard IBM poling 
techniques to read telemetry bursts coming from the DEC LSI-11 via a 
RS232. This is required to ensure the validity of the passed data stream; 

3.2.7. 1 Inputs . 

Telemetry from the HST EPS Testbed. 

3. 2. 7. 2 Processing . 

The Interupt Handler will pick up each character from the communication 
network and place it in a circular buffer which can then be accessed by 
the Data-Handler programs. Write and read pointers will keep track of 
information position in the buffer. An EOF designates no data. 

3 . 2 . 7 . 3 Outputs . 

Output will be a buffer in which telemetry characters have been stored. 
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3.2.8 Function PROLOG initialization . 

This program is automatically executed whenever PROLOG is called. It will 
be used to load all the PROLOG programs for the Expert System, copy and 
load all necessary data files, and start up the Expert System. 

3 . 2 . 8 . 1 Inputs . 

No inputs. 

3. 2. 8. 2 Processing . 

Loads PROLOG programs and data files, and then executes the Expert System. 

3 . 2 . 8 . 3 Outputs . 

No outputs. 
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3.2.9 Function Start . 

This is the main driver for the Expert System. It is written in ProLog. 
Start calls all the other Prolog programs and also displays all the menus 
for the user interface. The Fault Diagnosis routine is called 
automatically if a fault has been detected. The other routines are called 
when the user selects them from the menus. 


3 . 2 . 9 ♦ 1 Inputs . 

There are two input files: 

Fault file - Contains a fault flag = 1 if there was a fault 

= 0 if no fault was detected. 


Current file 1 - Contains the current orbit number and a 

reconditioning flag for each battery 
= 1 for reconditioning 
= 0 no reconditioning. 

The remaining inputs to this program involve user selections to menus. 

3. 2. 9. 2 Processing . 

Start checks the fault flag and brings up Fault Diagnosis if a fault was 
detected. It then directs the system flow according to user selection to 

menus. They pick which section to view from a choice of Graphics, Battery 
Status and/or Advice. 


3. 2. 9. 3 Outputs . 

There will be four menus written to the screen to enable the user I o 
easily traverse within the Expert System. They are: 

Main Menu - 1. Graphics - Decision Support 

2. Battery Status 

3. Battery Advice. 

4. Quit 

Battery Selection - select Battery 1 to 6. 


Graphics Menu - choice of 12 plots for each battery, 

corresponding to Data files 1 to 12. 


Advice Menu 


1. Recondition the battery? 

2. Change the workload? 

3. Change the charging scheme? 


-\fter a selection is made from the Main Menu, a particular battery is 
chosen before Graphics, Battery Status or Battery Advice is called. Upon 
completion, another battery nay be chosen for viewing with respect to the 
Main Menu selection or* the user can return to the Main Menu. 
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3.2.10 Function Fault Diagnosis . 

This module performs Fault Diagnosis which is called if the fault flag = 
1. Telemetry from the HST Testbed indicating a serious malfunction will 

cause an alarm to be sent to the engineer and a shut down of the system. 
There are five categories that will trigger this action. They are: 

1. Power Supplies 

< 5 amps during first 5 minutes of charge phase. 

>= 8 amps for 1-SPAs (1,3,5,7,9,11). 

>= 16 amps for 2-SPAs (2,4,6,8,10,12,13). 
c. SPA current > 5 amps during discharge phase. 


a. 

b. 


SPA current 
SPA current 
SPA current 
SPA current 


Batteries 

a. Cell voltage 

b. Cell voltage 


<= 0 volts for any cell in any battery. 

> 1.55 volts for any cell in any battery, 


3. Load Banks 

a. Sum of 3 bus currents > 99 amps. 

b. Load < 5 amps on any single bus during discharge phase. 


4. Temperature 

a. Average of the 6 temperature sensors > 25 C or < -10 C. 

5. Communication 

a. Missing 3 consecutive telemetry bursts. 

3.2.10.1 Inputs . 

Two current data files are input: 

Current file 2 - Contains Phase (charge or discharge) 

Day_min 

Current from 13 SPAs (Solar Panel Array,) 

Voltage from 3 Busses 

Average Temperature per Battery (6) 


Current file 3 - Contains Battery Cell Voltages (23 per battery) 


3.2.10.4 Processing . 

Each of the above five fault conditions is checked individually comparing 
the current data files against the expected data values as predetermined 
by MSFC. 


3.2. 10.3 Outputs . 

Header is displayed, ’FAULT DIAGNOSIS FOR ORBIT . One or more of the 
above five fault conditions is reported as the source(s) of the fault 
along with the malfunctioning component and if possible its value. For 
example: Hard Short in cell 3 of battery 1, or 

Load on Bus 3 < 5 A, load bank error. 


15 



3.2.11 Function Status . 

The Status portion of the Expert System checks the selected battery for 
reconditioning, temperature, workload, charging scheme and divergence. 

3.2.11.1 Inputs . 

Data files are used as input. 

Data file 1 - File contains battery voltage at EOD for last 12 orbits, in 
chronological order. 

Data file 2 - File contains the battery voltage during high in-charge 

for last 12 orbits. 


Data 

file 

orbits 

• 

Data 

file 

value 

and 

orbits 


Data 

file 

(degrees C 

Data 

file 


Data file 8 - File contains the averages of the six temperature sensors 

, at two minute intervals over the latest orbit. 

9 - File contains the average battery temperatures over entire 

orbit for the last 12 orbits. 

Data file 13 - File contains AHO summed over discharge phase per orbit;., 

for last 12 orbits. 

3.2.11.2 Processing . 

First check to see if the selected battery is being reconditioned. If so, 
stop this process since data will be misleading. Otherwise, four 
procedures are called to check selected battery performance. Averages 
(battery data averaged over 12 orbits) are used for the status analysis. 


CONDITION 

Temperature check (Data files 8 and 9) 

Temperature average over last orbit < 0 
and over last 12 orbits < 0 


STATUS 
=> Cold 


Temperature average over last orbit > 11 
and over last 12 orbits > 10 

Temperature average over last orbit > 11 
and over last 12 orbits < 10 


=> Hot or possible 
overcharging 

=> Possible 

overcharging 
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Workload Check (Data files 1 and 13) 

AHO average over last 12 orbits < 3. 
(3.0 Ampere-hours ) 

AHO average over last 12 orbits > 14. 

(14.0 Ampere-hours ) 

Charging Check (Data files 2 and 3) 

Recharge ratio average < 1.02 

and average high-charge voltage < 32.5V 


= > Underwork 


Overwork 


=> Insufficient 
Charge 


High-charge voltage > 33.8V 


=> Possible 

Overcharge 


Divergence Check (Data file 4) 

Divergence average > . 8V between => High divergence 

high and low cells 


High cell minus average greater than 
(average minus low cells) + 1 


=> Too many cells to 
low values 


3.2.11.3 Outputs . 

Header is displayed, ’STATUS FOR BATTERY #, ORBIT Messages aro 
printed to the screen detailing which of the above procedures is being 
checked and whether the battery seems healthy or whether there is a 
problem(s). The problem(s) is described giving condition and status of 
the component plus guidance as to where to get more information in the 
Advice or Graphics modules. 
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3.2.12 Function Advice . 

The Advice section goes into further detail than the Status section on 
three subjects: whether a battery needs reconditioning, changes in 

charging scheme, or changes in its workload. 

■3.2.12.1 Inputs . 

Inputs will be in the form of data files which will have been created by 
the Data-Handler . They are: 

Data file 1 - File contains battery voltage at EOD for last 12 orbits, in 
chronological order. 

Data file 2 - File contains the battery voltages during high in-charge 

period for each of the last 12 orbits. 

Data file 3 - File contains the recharge ratio = AHO/AHI per orbit for 12 
orbits . 

Data file 4 - File contains cell voltages at BOD, with the high value, low 
value and average of all values, in this order for each of the last 12 
orbits 

Data file 9 - File contains the' average battery temperatures over entire 

orbits for the last 12 orbits. 

Data file 10 - File contains the 23 cell pressures taken at EOC and then 

EOD for each battery in the last full orbit. 

Data file 13 - File contains AHO summed over discharge phase, per orb^^ 

for last 12 orbits. 


3.2.12.2 Processing . 

Trend analysis and averaging calculations will be performed for the 
following parameters, data read from the above data files: 


Reconditioning 

EOD batt voltage 

in-charge high voltage 

recharge ratio 

EOD cell divergence 

in-charge cell divergence 


Charging Scheme 
in-charge high voltage 
recharge ratio 
temperature 

Avg in-charge cell diverge 
Avg EOD cell pressure 
Avg EOC cell pressure 


Workload 

EOD batt voltage 
EOD cell diverge 
Avg AHO 


Trends will be expressed as none, slightly_up, up, strongly up, 

slightly down, down and strongly down. Trends will be calculated by using 

two simple mathematical functions. They can be expressed as: 
n-1 n n 

2 X(i) 2. i ♦ X(i) 

i = 1 i = 1 

where i <= 1 to 12 orbits and X(i) are the associated parameters. 
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The difference between the weighting functions is taken and then compared 
to hand crafted deviation factors to determine the trends. The first 
function weights all parameter values for a battery equally, while the 
second function weights the recent parameter values more heavily. For a 
list of constant values, the two functions are equal. 

Divergence is simply computed by taking the differences between 
corresponding values of two lists as high-voltage cells and low-voltage 
cells. 

For reconditioning, 11 conditions need to be checked for a particular 
battery: 

1. EOD voltage strongly down, in-charge divergence strongly up ~> 
reconditioning advised. 

2. EOD voltage strongly down, in-charge voltage strongly down => 
recondition soon. 

3. EOD divergence strongly up, in-charge divergence strongly up => 
strongly rising divergence indicates reconditioning. 

4. Voltage trends strongly down or down, recharge ratio and divergence 
trends strongly up or up => reconditioning is indicated by all 5 
trends . 

5. Recharge ratio strongly up => reconditioning indicated. 

6. In-charge voltage is down or strongly down, in-charge divergence 
is up or strongly up -> reconditioning recommended. 

7. EOD voltage down or strongly down, in-charge divergence up or 
strongly up => reconditioning indicated. 

8. EOD and in-charge divergence both up => consider reconditioning. 

9. Recharge ratio up => consider reconditioning. 

10. Both EOD and in-charge voltages down => consider reconditioning. 

11. None of the above => no need for reconditioning at present. 

To determine if the charging scheme for a battery should be changed, nine 
conditions are checked: 

1. Temperature strongly up, EOD pressure greater than 120, EOC pressure 

greater than 140 => overcharging causing high pressure. 

2. In-charge voltage strongly up => check for overcharging. 

3. EOD pressure greater than 110, EOC pressure greater than 135 => 

charge rate may be too high. 

4. EOD voltage strongly down, in-charge voltage strongly down => 
undercharging may be seriously affecting capacity. 

5. EOD voltage down, in-charge voltage down => undercharging. 

6. EOD voltage strongly down or down, in-charge voltage strongly down 
or down => undercharging may be causing loss of voltage. 

7. EOD voltage down, in-charge divergence greater than .8 => 

undercharging may be causing loss of voltage. 

8. EOD voltage strongly down, in-charge divergence greater than .8 
=> undercharging may be causing serious loss of voltage. 

9. None of the above => no need to change charging scheme. 
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Six conditions are checked to advise as to battery workload change: 

1. BOD voltage down, BOD divergence down, AHO average less than 25 =' 
loads probably too light. 

2. BOD voltage strongly down, BOD divergence strongly down, AHO average 

less than 5 => losing capacity due to memory effect, try heavier 

load . 

3. AHO average greater than 14 => possibly destructive overwork. 

4. AHO average greater than 9 => heavy workload. 

5. BOD voltage down or stongly down, BOD divergence down or strongly 

down, AHO average above 6 => losing capacity, consider 

reconditioning. 

6. Mone of the above => no need to change workload. 

3.2. 12.3 Outputs . 

A header is displayed, ’ADVICE FOR BATTERY #, ORBIT #’. Messages are 
printed to the screen detailing which of the three choices is bein 
examined and what the trends are for a particular battery. Given th 
condition, corrective action is recommended as reconditioning the battery, 
changing the workload or changing the charging scheme along with an 
explanation. Support of these decisions can be gotten from by viewing the 
plots detailed in the next section. . 


0> cot 




3.2.13 Function Graphics . 

Graphics supply the user with decision support in the form of 12 plots and 
histograms for a selected battery. 

3.2.13.1 Inputs . 

Graphics uses Data file(i) (i = 1 to 12) as inputs. Other input comes 
from user menu selections which determine which of the 12 graphs to plot 
and for which battery. 

3.2.13.2 Processing . 

The appropriate data file is read to get the data for the selected 
battery. Graphics primitives are used draw color plots of the data. 
Titles, vertical and horizontal captions are printed along with battery 
number and current orbit. The lists of data are then plotted, point by 
point . 


3.2.13.3 Outputs . 

Output consists of 12 plots for any battery (1-6) corresponding to the 12 
Data files. 



1 . 

2 . 

3. 

4. 

5. 

6 . 

7. 

8 . 
9. 

10 . 

11 . 

12 . 


Battery Voltage at BOD for last 12 orbits 

Battery Voltage at high in-charge for last 12 orbits 

Recharge ratio for last 12 orbits 

Cell Voltages at EOD; high, low, average for last 12 orbits 

Cell Voltages at high in-charge; high, low, avg, last 12 orbits 

Cell Voltages at BOD for latest orbit 

Cell Voltages at high in-charge for latest orbit 

Average Battery Temperature for latest orbit, each 2 min 

Average Battery Temperature for last 12 orbits 

Cell Pressures at EOC and BOD for latest orbit 

Time on Trickle Charge for last 12 orbits 

Battery Current during reconditioning, 1 orbit, each 2 min 


The user will be able to get a hardcopy of the plot as displayed on the 
screen . 
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3.3 Special Requirements . 

The following paragraphs will give 
requirements which will affect the design 


a description 
of NICBES. 


of 


the 


special 


3.3.1 Programming Method(s) . 

Structured Programming methods will be applied 
Data-Handler . The Expert System routines will 
is a logic programming language. Although 
follow structured programming techniques due to 
will be modular and somewhat procedural. 


to the ’C’ routines in the 
be written in Prolog which 
the Expert System can not 
its inherent qualities, it 


3.3.2 Program Organization . 

The Oata-Handler and the Expert System will 
systems whose only dependencies are the data files 


be built as two separate 


3.3.3 Modification Consideration. 


There will be no 
Data-Handler. The 
factors and ranges 
to running the Expert 


allowable modificat 
Expert System will 
of the plots. These 
System. 


ions during operation of 
allow adjusting of the devia 
modifications must be made p 


t he 
t i on 
r ior 


3.3.4 Special Features . 

Print statements to facilitate the testing of the Data-Handler will be 
left in the programs, but commented out for actual system execution. 

3.3.5 Expandability . 

Due to the moderate size of NICBES, there is adequate room for expansion. 
However true expansion to its function would best be done on a 
multi-tasking computer. 

3.3.6 Special Timing . 

Since the Data-Handler and the Expert System will be developed and tested 
independently, there are no special timing requirements. 


3.4 Human Performance . 

The Expert System will be an entirely interactive system whereby the user 
will make selections from menus to direct the type of information 
desired. The menus are described in Section 3.2.8. 3. Responses to menus 
will usually be item number selection. Response checking will occur after 
each user entry. There are no time or order constraints imposed upon user 
input. Displays will remain on the screen until the user opts to 
continue. 
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3.5 Data Base Requirements . 

.MICBES is a data driven model. In the following paragraphs exact data 
base requirements will be listed. 

3.5.1 Sources and Types of Input . 

Input to the Data-Handler is in the form of telemetry bursts, each 
containing 370 values - one per line, routed from the DEC LSI-li to the 
I3M-PC AT every one minute. Following is the format: 

Start of Telemetry Burst 
A 


Header Information (Integer) 
year 

day of year - 198X 

hour - 0 to 24 

minute - 0 to 60 

second - 0 to 60 

orbit - Positive Integer 

phase - 0 for discharge, 1 for charge 

day minute (minute in charge) - 0 to 70 

night minute (minute in discharge) - 0 to 37 


Battery Information (for each of 6 b 
battery number 
cell voltage 
cell pressure 
battery voltage 
battery current 


bprc current 
temperature sensors 
battery reconditioning 

Miscellaneous Information 
Solar Array current 
Bus Voltage 
Bus current 

Reals are five place floating point 


tteries ) 

Integer 1-6 
23 Reals -2 to +2 volts 
23 Integers 0 to 150 psi 
Real 0 to 40 volts 
Real -30 to +25 amps 

negative for discharge phase 
positive for charge phase 
Real 0 to 5 amps 
6 Reals -15 to 30 (degrees C) 
Integer 0 for no, 1 for yes 


13 Reals 0 to 20 amps 
3 Reals 0 to 40 volts 
3 Reals 0 to 90 amps 

umbers. 


Inputs to the Expert System are the data file outputs of the Data-Handler, 
see Section 3.24 for a complete description. All other inputs to the 
Expert System are user selections to menus. 
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3.5.2 Destination and Types of Outputs . 

Output from the Data-Handler is in the form of data files which will be 
used as input to the Expert System. All the battery data files and their 
format are listed under section 3. 2. 4. 2. 

Output from the Expert System is in the form of reports, explanations, 
analysis and graphs. No data files are created. 

3.5.3 Internal Tables and Parameters . 

Global structures and parameters for the Data-Handler will be set-up in an 
include file. All parameters in the Expert System will be passed to 
functions as needed, i.e., no global parameters. 


3.6 Adaptation Requirements . 

NICBBS will be written specifically for analysis in support of the Hubble 
Space Telescope Testbed. Adaptations to other EPSs will require seperate 
efforts, although the concepts may remain the same. 


3.7 Government-Furnished Property List . 

No Government property will be used in the development of NICBES. 
the following hardware and software are required at Marshall Space 
Center for NICBBS installation and demonstration: 

Hardware Software 


However 

Flight 


DEC LSI-11 
IBM-PC AT 

STAH-SD-15 Printer 
RS232 


MICROSOFT C 

ARITY PROLOG Version 4.1 


SECTION 4. QUALITY ASSURANCE PROVISIONS 

4.1 Introduction and Definitions . 

In order to assure functionality and accuracy of NICBES several types of 
testing will be conducted. All testing will be conducted during 
development at MMDA. The final system installation and demonstration will 
be performed at MSFC at the time of delivery. 

4.2 Testing Structure . 

The test program will be structured into the following four levels of 
testing. 
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4.2.1 Module/Unit Testing . 

Module/Unit tests are the first informal tests which will be conducted by 
the programmer prior to establishment of the test baseline. iModule/unit 
testing will demonstrate the accuracy of the operations indicated in the 
functional requirements, Section 3.2. Each module/unit will be tested 
using nominal, extreme and erroneous input values and will be tested for 
error detection and proper error recovery including appropriate error 
messages. Each decision option will be exercised to execute subordinate 
units performing input or output functions. 

4.2.2 Subsystem Integration Testing . 

Subsystem integration tests are the final informal tests conducted by the 
programmer prior to establishment of the test baseline. Subsystem 
integration testing will demonstrate the accurate implementaion of 
interfaces between module/units . As each module/unit is integrated into 
the subsystem, the interface will be tested using nominal, extreme and 
erroneous input values and will be tested for error detection and proper 
error recovery including appropriate error messages. 

There are only two subsystems for NICBES, the Data-Handler and the Expert 
System Interface. 

4.2.3 System Integration Testing . 

System integration tests are the formal tests conducted by the programmer 
after establishment of the formal baseline. System integration testing 
will demonstrate the accurate implementation of interfaces between 
subsystems. As each subsystem is integrated into the system the interface 
will be tested for error detection and proper error recovery including 
appropriate error messages. The system size/memory requirements and 
execution time will be measured and evaluated. An integrated system test 
will be conducted to verify required performance. 

For the NICBES system integration test the Data-Handler will be evaluated 
with telemetry obtained from MSFC HST EPS Testbed over modems. This data 
will then be used to simulate the data communication network at MSFC by 
linking two IBM-PCs via a RS232 and transferring data at one minute 
intervals. The data files generated by the Data-Handler will then be used 
to evaluate the Expert System. 


4.2.4 System Demonstration . 

A demonstration based on the integrated system test will be conducted at 
Marshall Space Flight Center upon delivery and installation of the 
software . 
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4.3 Testing Techniques . 

Testing will incorporate two fundamental methodologies. 

4.3.1 Structure-Based Path Testing . 

Path testing will be employed for module/unit level testing. The 
objective of path testing is to exercise enough differnet paths through 
the logic structure of a module/unit to demonstrate the accuracy of the 
processing performed on the data. A path equates to an executable 

instruction sequence that starts at a module/unit’s entrance and ends at 
its exit and may consist of one or more of the operations identified in 
the functional requirements, Section 3.2. Enough paths are required to 
ensure that every instruction in the module/unit has been exercised at 
least once and every decision has been executed in each posssible 
direction at least once. 

4.3.2 Top-Down Integration . 

Top-down integration will be employed for both subsystem integration and 
system integration levels of testing. The objective of top-down 
integration is to build a string of modules from the executive or control 
module. Modules will be added to the string in increments to allow 
testing of individual interfaces. Modules not yet integrated are 
simulated by stub routines as integration progresses by adding individual 
modules and testing each interface. 


4.4 Test Documentation . 

Test documentation will be written in the Test Plan, Test Procedures and 
Test Report. 

4.4.1 Documentation of Test Plan . 

Test implementation information will be stated in the test plan and will 
specify the following: 

1. Facility resources and location. 

2. Schedule. 

3. Manning requirements. 

4. Preparation of input data. 

5. Software configuration. 

6. Organization of test operations. 

6. Output analysis techniques. 

4.4.2 Documentation of Test Procedures . 

A Test Procedures document will be written to accompany the Test Plan. It 
will reflect the following: 

1. Program initialization instructions. 

2. Operator interfaces. 

3. Input Data; 

4. Required operator responses. 

5. Test event sequence. 

6. Information recording requirements. 

7. Program termination/restart instructions. 
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A Test Reports document will be written to accompany the Test Plan and 
Procedures. This document will relect the following information: 

1. Actual test results. 

2. Criteria successfully met. 

3. Deviations from expected results. 

4. Reasons for deviations. 

5. Recommendations. 


4.5 Verification Cross-Reference Matrix. 


Function 


Test Requirement 


3.2.1 Function Main 

3.2.2 Function Initialization 

3.2.3 Function Read Data 

3.2.4 Function Process Data 

3.2.5 Function Write Data 

.6 Function Finish 
.7 Function Interupt Handler 

3.2.8 Function PROLOG Initialization 

3.2.9 Function Start 

3.2.10 Function Fault Diagnosis 

3.2.11 Function Status 

3.2.12 Function Advice 

3.2.13 Function Graphics 


Appropriate subroutines called 
Communication ports operate 
Data reading starts at beginning of 
of orbit 

Telemetry read and put in 
structured array 
Telemetry processed and put in 
correct matrix or array 
Processed data written to files 
at appropriate times and in 
correct format 
Data-Handler is exited 
Telemetry is read from the DEC 
LSI-11 via RS232 and put in 
accessable buffer 
Programs loaded and Expert System 
started 

Menus appear in proper order and 
appropriate modules are called 
If fault flag, diagnosis anomaly 
correctly 

Battery temperature, workload, 
charging, divergence and 
reconditioning checked accurately 
Advice for battery reconditioning, 
charging and workload from trend 
analysis matches expert opinion 
All 12 plots are accurately drawn 
on the screen 
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SECTION 5. PREPARATION FOR DELIVERY 

Delivery will include the entire NICBES software package recorded on 
diskettes plus all deliverable written documents. After coordinating wxth 
C&DM, the above media will be hand carried to MSFC in Huntsville, Alabama 
at the time of NICBES installation and demonstration. 
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APPENDIX A 

HUBBLE SPACE TELESCOPE BATTERY TESTBED 


NASA and 
spacecraft . 
studies and 
candidate for 
know ledge- based 


MSFC are involved in the development of autonomous systems for 
The electrical power system has been identified in several 
by the Advanced Technology Advisory Committee as a leading 
implementing advanced automation approaches such as 
and expert systems. The HST EPS Testbed provides an 


opportunity to take 
EPS for spacecraft. 


a significant step toward autonomous operation of an 


Power for the HST comes from a system of 20 SPAs and 6 23-cell 
nickel-cadmium batteries. The HST EPS is simulated by and EPS Testbed at 
MSFC. Each battery has two power supplies associated with it, divided 
into 1-SPA and 2-SPA. A seventh 2-SPA brings power directly into the bus 
distribution system. These 13 power supplies simulate the 20 SPAs. 
Figure 2 is a schematic diagram for the testbed. 


The testbed at MSFC was built to simulate the HST EPS as closely as 
practical. There are 6- charge current controllers (CCC) that control the 
operation of various relays that disconnect (when a temperature-dependent 
voltage level is reached) and connect SPAs to the batteries. Each CCC 
controls 3 SPAs; a K2 relay controls one SPA and a K1 relay controls two 
SPAs. Thus only tow power supplies are needed per battery. The 13th 
power supply simulates the two SPAs that are connected directly to the 
diode bus. 


The batteries are diode isolated from each other. Each two batteries are 
connected to three diode busses. The diode busses then feed three 
independently controllable load banks. As on the flight HST, each battery 
can be switched to a reconditioning load and its associated SPAs can be 
switched to one of the other two diode busses. 


The batteries are mounted three each on two aluminum plates in a single 
temperature chamber. Each plate has a heater element that can control the 
battery temperature up to 10 degrees Celsius above the chamber ambient 
temperature . 

Also incorporated in the testbed is a microprocessor controller that was 
built and programmed at MSFC. This control computer (CC) controls the 
temperature of the batteries; it controls the load banks in either a 
constant current or constant power mode; it can maintain a tape charge on 
the batteries; it controls the over-voltage diode trip point; and it 
senses CCC relay operation and controls the 13 power supplies in much the 
same fashion as the HST 0F224 flight computer controls the SPA trim relays 
for a step to trickle charge. 
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This testbed development work was performed by several people at MSFC. 
John R. Bush was responsible for the HST breadboard and controller. John 
A.Pajak was responsible for the data system and the associated maze of 
wiring. Rober E. Kapustka was responsible for the battery protection and 
recontioning ciruits (bprc). John R. Lanier is the team leader of EPS 
Systems Team which has responsibility for this testbed. 


A3 



APPENDIX B 


NICKEL-CADMIUM BATTERIES 


Nickel-Cadmium batteries are appropriate energy storage media for a wide 
range of applications. They exhibit a combination of high capacity, long 
life and low maintenance requirements. There is, however, much that is 
unkown about the behavior of these batteries, both in terms of design and 
manufacture, and operating characteristics. Even persons who have been 
working with these batteries for over 15 years, say that there is no such 
thing as a battery expert. 

General statements can be made about Nickel-Cadmium batteries. The must 
important factors affecting their performance, ignoring design and 
manufacture, include ambient temperature, depth of discharge, and charging 
scheme. It has been observed tat occasional changes in such operating 
parameters can be of marked benefit in the life cycle of the cell. 

As the batteries go through a great number of charge - discharge cycles, 
aging takes place, due largely to electrolyte migration, separator 
deterioration, hydrogen generation because of overcharging, and memory 
effect. This last condition is a result of utilization of only a small 
part of the battery’s capacity over a number of charge - discharge cycles, 
causing a change in the crystalline structure of the metals on the 
plates. Reconditioning is done by draining a battery completely, and 
holding it at a low potential for a period of time, then recharging the 
battery. This rebuilds a finer crystalline structure and restores much of 
the battery’s capacity. Reconditioning ip a strain O'n the battery and 
should not be undertaken lightly, but is a valuable tool in enhancing 
battery capacity. Eventually, deterioration of the battery goes too far, 
and reconditioning can no longer restore usefulness. 

During the draining procedure of recondition, a weak cell can undergo 
reversal, causing permanent damage. The BPRC prevents this occurrence. 
BPRCs protect each cell of the batteries. 

During battery operation, cell voltages tend to diverge, migrating into 
groups of strong cells and weak cells. As cells get weaker, they do no 
carry their share of the load, which must be taken up by the stronger 
cells. Need for reconditioning is indicated by a high divergence, a low 
EOD voltage and particularly by both conditions together. A low EOC 
voltage, particularly if accompanied by a low recharge ratio (ampere hours 
in divided by ampere hours out), usually indicates that the battery is 
being insufficiently charged. 
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If a Nickel-Cadmium battery is overcharged, hydrogen gas is generated 
causing a sharp increase in cell pressure. Since the hydrogen is not 
recombined, it is possible that a cell may rupture. Another problem due 
to overcharging is heat production, causing an increase in intake of 
current, causing more heat production, and leading to thermal runaway and 
battery self-destruction. Care must be taken so that overcharging does no 
occur, usually by shutting off power when a certain cell voltage is 
reached. After main charge is shut off, the battery remains on trickle 
charge for the rest of the charging cycle, a non-destructive "topping off" 
of the charge. 

Decision to recondition, change charging scheme or adjust workload are 
presently made by rule of thumb and intuition gained from years of 
experience. Battery management remains a difficult subject. 
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